home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1993…ch: Other People's Memory / ADC Developer CD (1993-03) (''Other People's Memory'')_iso / Dev.CD Mar 93.iso / Development Platforms / Apple II / Essentials / Technical.Notes / IIGS / TN.IIGS.078 < prev    next >
Encoding:
Text File  |  1992-07-15  |  6.0 KB  |  120 lines  |  [TEXT/GEOL]
  1. Apple II
  2. Technical Notes
  3. _____________________________________________________________________________
  4.                                                   Developer Technical Support
  5. Apple IIgs
  6. #78: Bank Alignment and Memory Management
  7.  
  8. Revised by: Matt Deatherage                                          May 1992
  9. Written by: Matt Deatherage                                        March 1990
  10.  
  11. This Technical Note discusses the way the Memory Manager deals with requests
  12. for memory that is already in use, and why this can be really annoying.
  13.  
  14. CHANGES SINCE MARCH 1990:  Included new information about some smarter
  15. algorithms in System Software 6.0 and later which can avoid problems some of
  16. the time.
  17. _____________________________________________________________________________
  18.  
  19.  
  20. The Memory Manager is a sophisticated software module that provides the
  21. framework for the allocation, moving, management, and disposal of blocks of
  22. memory; however, it's not magic.
  23.  
  24. When you ask the Memory Manager for a block of memory and it's not immediately
  25. allocatable, the Memory Manager starts through the procedure for purging,
  26. compacting, and calling out-of-memory (OOM) queue routines until, at the end
  27. of its rope, it finally gives up and returns error $0201.  The exact procedure
  28. is repeated below, taken from Volume 3 of the Apple IIgs Toolbox Reference.
  29. Note that each successive step is only taken if, after the previous step, the
  30. requested memory still isn't available.
  31.  
  32.    1. Calls each OOM queue routine until either all routines have been called
  33.       or until one OOM queue routine reports that it has freed enough memory
  34.       to satisfy the request.
  35.    2. Compacts memory.
  36.    3. Purges all level 3 handles.  If this frees enough memory, compaction
  37.       occurs.
  38.    4. Purges all level 2 handles.  If this frees enough memory, compaction
  39.      occurs.
  40.    5. Purges all level 1 handles.  If this frees enough memory, compaction
  41.       occurs.
  42.    6. Calls each OOM queue routine again until all have been called or until
  43.       one OOM queue routine reports that it has freed enough memory to
  44.       satisfy the request.
  45.    7. Gives up and returns error $0201.
  46.  
  47. This strategy works pretty well--as long as the request is for a block of
  48. memory wherever it fits.  If someone has asked the Memory Manager for memory
  49. at a specific address, things get stickier.
  50.  
  51. Suppose that you've asked the Memory Manager for a handle starting at the
  52. beginning of bank 2, and that something else (i.e., the ProDOS FST) is already
  53. using that memory.  The Memory Manager notices that the handle isn't
  54. immediately available, so it starts going through the listed procedures.
  55. Since the handle for the ProDOS FST is neither purgeable nor movable and GS/OS
  56. isn't likely to give it up in an OOM queue routine, the request fails and the
  57. Memory Manager returns error $0201.
  58.  
  59. However, the Memory Manager went through all the steps listed to get to the
  60. seventh step, the error.  The Memory Manager has no way to know that one of
  61. the OOM queue routines isn't going to give up that particular handle and allow
  62. the request to be fulfilled.  The OOM queue routines cannot know themselves,
  63. since they are only told how much memory is needed, not where it has to be.
  64. Therefore, whenever the Memory Manager returns error $0201, all purgeable
  65. handles have been purged.
  66.  
  67. This is particularly annoying to loaders.  OMF supports a "bank-aligned"
  68. attribute for load segments, and the loaders ensure that such segments are
  69. loaded at the beginning of some bank or another.  The Memory Manager does not
  70. have a "bank-aligned" attribute for handles, so the loaders have to do these
  71. things themselves.  They do this by asking for a handle of the appropriate
  72. size at the beginning of bank two.  If this fails, the loaders try again with
  73. bank three, then bank four, and so on through the end of memory.
  74.  
  75. Since some part of GS/OS is almost always occupying the memory at the
  76. beginning of bank two, which is where the loader first attempts to load a
  77. bank-aligned segment, the presence of such a segment in a load file virtually
  78. guarantees that all purgeable handles are purged when the file is loaded.
  79. This kicks out dormant applications and zombie-state tool sets, among other
  80. things, requiring they be loaded from disk again when needed.
  81.  
  82. Starting with System Software 6.0, the Loader attempts an alternate strategy
  83. first--it tries to allocate an entire bank of memory that is page aligned and
  84. doesn't cross a bank boundary.  This block, if available, will by definition
  85. be bank-aligned.  Since code segments can't be larger than 64K, such a block
  86. can always hold a bank-aligned segment.  The Loader now tries to allocate such
  87. a block and if it finds one, it immediately disposes of it and allocates a
  88. block of the right size at the same bank address.
  89.  
  90. If this strategy succeeds, it's a lot faster than the other method and may
  91. avoid purging all of memory.  If it fails, though, the Memory Manager still
  92. goes through all seven steps before returning error $0201, so all of memory
  93. may still be purged.  It's just less likely in System Software 6.0 and later.
  94.  
  95. It doesn't make sense to bank-align a small segment, and small segments fit
  96. better into fragmented memory.  If you use large segments anyway, consider the
  97. trade-off:  bank-aligning a segment may purge memory at load time, but your
  98. linker may be able to generate smaller OMF, decreasing disk size and load
  99. time.
  100.  
  101.  
  102. SUMMARY
  103.  
  104. The general recommendation against asking for specific blocks of memory is
  105. well-known to most developers; the reasons outlined above simply add fuel to
  106. the fire against such programming practices.  What isn't as widely known is
  107. that having a bank-aligned load segment in a load file may cause everything
  108. purgeable to be purged, and could also cause OOM queue routines to dispose of
  109. handles when there really isn't any kind of memory shortage.
  110.  
  111. Apple advises developers to carefully consider the advantages and
  112. disadvantages of bank-aligned segments before including one in a load file.
  113.  
  114.  
  115. Further Reference
  116. _____________________________________________________________________________
  117.  
  118.    o   Apple IIgs Toolbox Reference, Volumes 1 and 3
  119.    o   GS/OS Reference
  120.